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METHOD AND APPARATUS FOR INTELLIGENT, SCALABLE 
COMMUNICATIONS IN A MULTI-ASSET FINANCIAL FULFILLMENT 

NETWORK 

Cross Reference to Related Applications 

5 This application hereby incorporates U.S. Application No. 09/684,208, filed 

October 6, 2000, by reference in its entirety. This application claims the benefit under 
35 U.S.C. §119(e) of the filing date of U.S. Provisional Application No. 60/251,077, filed 
December 4, 2000, which is hereby incorporated by reference in its entirety. 

Field of the Invention 

Jh 10 The present invention relates generally to a method and apparatus for providing 

uniform, intelligent, and scalable communications between disparate entities on a multi- 
O asset, financial fulfillment network. 

Description of Related Art 
Computers in networks interconnecting disparate businesses, such as networks 
f y 1 5 including two or more computer systems that communicate with each other to perform 
various functions such as loan processing and other financial transactions, typically do 
O not (or cannot be counted on to) communicate using a single, standard messaging 

protocol, data format, or document format. As a result, the computer system of an entity, 
such as a lending institution, may have to be specially configured to communicate with 
20 each of potentially many different computer systems to send, receive, and appropriately 
respond to information from other systems. For example, if a merchant wishes to submit 
a loan application electronically to several different lenders using the merchant's 
computer system, the merchant's computer system may have to be configured specially 
to format or otherwise package the loan application information in a different way for 
25 each lender's computer system to which the application is sent. In addition, the 

merchant's computer system would have to incorporate the capability to interact with the 
lender's remote computer system in order to fulfill requirements that are unique to a 
particular lender in order to complete the credit application. Furthermore, these 
interactions would have to be customized for each type of credit application, e.g., loan, 
30 lease, etc., because of the disparate information requirements of these products. These 
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requirements may make it difficult for a merchant or other entity to access financial 
services and may discourage the merchant or other entity from even attempting to access 
the financial services of others using electronic means, 

5 Summary of the Invention 

Illustrative embodiments of the invention provide a variety of different aspects 
that combine to provide a widespread and scalable electronic financial fulfillment 
network that may be accessed by a number of different computer systems. In one 
illustrative embodiment, communication between computer systems external to a 

10 financial fulfillment network and systems within the financial fulfillment network may 
be managed xising a Financmg Application Programming Interface (API). The financial 
fulfillment network, such as a financing system described in U.S. Patent Application No. 
09/684,208, filed October 6, 2000 and titled "Method and Apparatus for Processing 
Financing Applications", may include a computer system or network of computer 

15 systems that operate financing service modules and conamunicate with external systems. 
That is, such a computer system may, for example, handle requests for financial services 
from the external systems and responses to the requests. The financing service modules 
may provide any suitable financing service, such as processing factoring transactions, 
trade credit transactions, leasing transactions, escrow transactions, credit insurance 

20 transactions, letter of credit transactions, credit card transactions, payment netting, funds 
transfer, aspects of any of them, and so on. As one example, a loan application 
processing module operating within the financial fulfillment network may automatically 
process a loan application submitted by an external computer system in a financial 
services request and send a decision to approve or decline the application back to the 

25 external computer system. The financing service modules may be operated on behalf of 
lending institutions or other entities that have authorized their financing service 
decisioning logic to be implemented within the financial fulfilhnent network. 

In one aspect of the invention, a Financing API may be configured such that all 
communications between external computer systems and the financial fulfillment 

30 network are formatted based on a xmiform set of messaging rules, i.e., the messaging 
protocol used between the communicating devices reflects a set of predefined message 
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portions (or information packets (not to be confused with the use of the term "packef in 
a networking sense; thus, an "information packef may be transmitted in a non- 
packetized format or if in a packetized format, as one, more than one or less than one 
packet on a communications channel or network)), specialized to facilitate the clearing of 

5 the financing transactions and available to system users as a common interchange 
language. The message portions themselves are relatively insensitive to the sequence 
and/or combinations in which they are invoked, allowing for a multitude of behaviors on 
the part of disparate on-line users/applicants. For example, the message portions may be 
combined in a variety of different ways to form a variety of different messages, thereby 

10 allowing the Financing API to support a variety of different financial services. 

Furthermore, in another aspect of the invention, the set of message portions that 
comprise the Financing API are collectively exhaustive, in that they uniquely define the 
allowable user cases, manifested by users of a variety of financial services transactions. 
Thus, even though different external computer systems may use different operating 

15 systems and/or different financing transaction applications (such as loan application 

decisioning applications), the external computer systems may all communicate with the 
financial fulfillment network and may communicate with each other through the financial 
fulfillment network. This ability to communicate in a uniform way with the financial 
fiilfillment network, i.e., by using a same API, may allow an entity to access the 

20 financing services of the network itself as well as the financing services of other entities 
having external computer systems that communicate with the financial fulfillment 
network and potentially other financial networks. 

In another aspect of the invention, a Financing API may be structured to allow 
fiinctionality to be added to the financial fiilfillment network, e.g., additional financing 

25 services, without requiring any change to the messages or message portions used by the 
Financing API, or at least without requiring substantial change to the messages or 
message portions. For example, if a new financing service is added to the financial 
fiilfillment network, existing sets of messages or message portions in the API may be 
used to support the new financing service. In some cases, a new financing service may 

30 require one or more new messages or message portions to be added to those supported by 
the API, but in general the new financing service can be supported in large part by 
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existing messages and/or message portions or combinations of message portions in the 
API. 

In another aspect of the invention, the Financing API has a hierarchical structure 
that is used to structure the content of communications regarding a financing service 

5 provided through the financial fulfillment netw^ork. For example, the hierarchy may 
include the top-down levels of (1) overall or high-level type of financing service 
requested (self-finance decisioning, financing by outside entities, etc.), (2) type of 
customer (consumer, business, etc), (3) type of asset financed (equipment financing, 
trade financing, etc.). (4) type of credit products available (loan, lease, etc.), (5) sets 

10 and/or sequences of operations to be performed (i.e., communications operations needed 
to provide the financial service), (6) specific operations details, and (7) information 
packets to be used in the communications (e.g., specific variables or other pieces of 
information needed to provide the service). Thus, commimications for each fin^cing 
services transaction can be logically organized using a hierarchy to define the parameters 

15 of the financing services to be provided and structure the content of the messages used to 
provide the service. The hierarchical organization can make a more efficient use of 
messages or information packets supported by the API (e.g., by allowing customized sets 
of information packets to be used for a variety of different transactions through the use of 
different combinations and sequences of a relatively small set of standard information 

20 packets) and more easily allow the integration of new financing services into the 

financial fidfiUment network (e.g., alterations may be made in the hierarchy without 
affecting the operations of previously supported financing services). For example, in one 
aspect of the invention, an item in a selected level in the hierarchy may define a unique 
set and/or sequence of items firom one or more lower levels in the hierarchy, while items 

25 in the lower levels may depend on (i.e., may vary according to) items at levels higher 
than the selected level in the hierarchy. 

In another aspect of the invention, the Financing API may allow for interactive 
commimications to occur during a financial services transaction. This interactive 
capability may allow a financial service to be tailored to each particular application and 

30 reduce inefficiencies in obtaining financial services. For example, a remote loan 

processing system operating with the financial fulfillment network may be configured to 



intelligently request the applicant to supply additional information beyond that provided 
in an initial loan application, and incorporate this additional information in making the 
ultimate credit decision connected with the apphcation. Further, the remote loan 
processing system may also allow the applicant to interactively monitor the status of the 
5 decision associated with the application for credit, providing appropriate responses to ad- 
hoc user queries. 

In an illustrative embodiment, a merchant may submit a loan application to a 
financial fulfillment network using the Financing API request format. The API request 
format may be structured, for example, so that the loan application information is 
O 1 0 provided in a uniform way using a set of organized information packets regardless of the 
ti entity or computer system submitting the information. Upon receiving the request firom 

^ the merchant, the financial fiilfiUment network may process the request, e.g., submit the 

iri data associated with the loan application to a loan application decision process and 

^ respond with a decision that is relayed back to the applicant via appropriate Financing 

15 API messages. This method of seamless data transfer between possibly disparate 
5 computer systems, in which the data from the applicant's computer, via the Financing 

t API request interface, is incorporated into a process automation system operating within 

^ the financial fiilfillment network, allows for intelligent and scalable communication. 

Furthermore, the Financing API allows for internal rules-based engines to incorporate 
20 information received by the host system via the Financing APIs into the credit approval 
logic to approve or decline a loan application, and update intemal data storage devices 
with the received information. In addition, the Financing API allows for the loan 
processing engine residing on the financial fulfillment network to interactively request 
additional information fi-om the applicant, or from other systems (either third party, or 
25 intemal) that contain relevant data with which to enhance the quality of the credit 

decision process. The rules associated with the credit decision process may be arbitrary, 
in that they are completely specified on the financial fiilfillment network by the 
underwriters of the credit application, or they may include routing rules in which the 
information required for the credit decision is forwarded to a set of financial institutions 
30 that may imderwrite the application via the Financing API. In addition to processing a 
financial services request entirely within the financial fiilfillment network, other external 
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computer systems (e.g., computer systems operated by various financing institutions) 
may receive a sei*vices request, process it, and send a response back to the merchant 
through the financial fiilfillment network using the Financing API. Thus, even though 
the merchant and the financing institutions may operate computer systems and/or 

5 appUcations that are quite different, the Financing API may allow the merchant to access 
the financing services of the financial fiilfillment network and/or other entities having 
systems that communicate with the financial fiilfillment network without requiring 
otherwise special communications formatting. 

Although in the illustrative embodiment above the merchant submits a loan 

10 application, the financial fiilfillment network and/or other external computer systems 
may be configured to handle any type of financing transaction including, but not limited 
to, a factoring transaction, a trade credit transaction, a leasing transaction, an escrow 
transaction, a credit insurance transaction, a letter of credit transaction, a cash transaction 
or any combination of these transactions, and other transactions as will occur to those 

15 skilled in the field of finance. 

Use of the Financing API to communicate with a financial fulfillment network 
may provide benefits to operators of computer systems external to the financial 
fulfillment network since the external systems may operate using any suitable operating 
system, hardware, software, logic, or other components and still be able to obtain and 

20 provide financing services through the financial fiilfillment network. So long as the 
external computer system can send and receive communications with the financial 
fulfillment network, the external computer system can communicate with any other 
system linked to the financial fiilfillment network as well as the network itself. In 
addition, financing service features may be added or changed in the external computer 

25 systems without requiring any change in the API. Thus, an operator of an extemal 

computer system may receive and provide different financing services without requiring 
any change in the API, or may enhance the offering of different financing services by 
adding to the set of messages defined in the Financing API. Use of the Financing API 
with the financial fulfillment network also makes the types and/or number of financing 

30 services that are available through the network scalable since both the systems in the 
financial fulfillment network and extemal systems may add and/or change the financing 



services provided without any fundamental change in the API being required. For 
example, a financing institution may initially provide only loan application decisioning 
services through the financial fulfillment network. As time passes, the institution may 
add other services, such as factoring services, that are provided through the network. 
Since the API may support the added services, the institution may need only to add 
support for messages in the API that are unique to the added services and components, 
(e.g., hardware, software, etc.) to its computer system and design the added components 
to be compatible with the API. Further, even if a financing service is added to the 
financial fulfillment network that requires a change to the API, the API may be relatively 
easily changed and tiie altered API used by systems communicating with the financial 
fulfillment network. 

Brief Description of the Drawings 

Aspects of the invention will be appreciated more fully with reference to the 

following detailed description of illustrative embodiments, when taken in conjunction 
with the accompanying drawings, wherein like reference characters denote like features, 
in which: 

Fig. 1 is a schematic block diagram of a computer system incorporating aspects 
of the invention; 

Fig. 2 is a flow chart of steps of a method for communication in accordance with 
an aspect of the invention; 

Fig. 3 shows an illustrative hierarchy for a commxmications interface in 
accordance with an aspect of the invention; 

Fig. 4 shows an illustrative set of values for levels in the Fig. 3 hierarchy; 

Fig. 5 shows an illustrative correspondence between operations and information 
packets in an illustrative embodiment; 

Fig. 6 shows an illustrative implementation of a transaction in an illustrative 
embodiment; and 

Figs. 7 and 8 show a correspondence between combination information packets 
and simple information packets in an illustrative embodiment. 
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Detailed Description 

Fig. 1 is a schematic block diagram of an illustrative embodiment that 
incorporates several aspects of the invention. In this illustrative embodiment, an 
applicant system 1 accesses financing services offered in connection with a financing 
5 network 2 and/or a lender system 3. It should be understood that the illustrative 

embodiment shown in Fig. 1 is only one example of an arrangement that may incorporate 
aspects of the invention. For example, any suitable nximber of applicant systems 1, 
financing networks 2, and lender systems 3 may be included. Further, the applicant 
system 1, the financing network 2 and/or the lender system 3 may include any suitable 

10 components or fimctions not described herein whether or not they are related to the 
operation of any of the systems in accordance with various aspects of the invention. 

The applicant system 1, financing network 2 and lender system 3 may be general 
purpose data processing systems, such as a suitably programmed general purpose 
computer, or network of general purpose computers, and other associated devices, 

15 including communication devices and/or other circuitry or components necessary to 
perform desired input/output or other functions. The applicant system 1, financing 
network 2, and lender system 3 can also be implemented, at least in part, as a single 
special purpose integrated circuit (e.g., an application-specific integrated circuit - ASIC), 
or an array of ASICs, each having a main or central processor section for overall, system 

20 level control and separate sections dedicated to performing various different specific 
computations, fimctions and other processes xmder tiie control of the central processor 
section. The applicant system 1, financing network 2, and lender system 3 can also be 
implemented using a plurality of separate, dedicated programmable integrated or other 
electronic circuits or devices, e.g., hard-wired electronic or logic circuits, such as discrete 

25 element circuits or programmable logic devices. These systems 1, 2, and 3 may also 

include any other suitable devices, such as one or more information display devices (e.g., 
a computer monitors or printers), user input devices, such as keyboards, user pointing 
devices, touch screens or other user interfaces, data storage devices, such as a volatile or 
non- volatile memory, communication devices or other electronic circuitry or 

30 components. 
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The applicant system 1 , financing network 2 and lender system 3 may 
communicate using a communications link 4. The communications link 4 may include 
any type of communication system, such as wired or wireless telecommunications 
networks, radio or infrared communications systems, the Internet, one or more wide-area 

5 or local-area networks, optical communications networks, combinations of any of them, 
and the like. In addition, communications may take place using any suitable format, 
protocol or other scheme to transmit information through the communications link 4. 

In this illustrative embodiment, the applicant system 1 includes at least a 
processing module 11, an applications programming interface (API) module 12 and a 

10 memory 13. The financing network 2 and the lender system 3 similarly include at least a 
processing module 21 or 31, an API module 22 or 32 and a memory 23 or 33. The 
processing modules 11,21 and 31 may be configured in any suitable way and may be 
similar to, or different from, each other. Likewise, the API modules 12, 22 and 32 may 
be configured in any suitable way. The processing modules 11,21 and 3 1 and the API 

15 modules 12, 22 and 32 may be implemented, at least in part, as software modules written 
in any suitable programming language that are executed on any suitable data processing 
apparatus in any suitable environment. Alternately, or in combination with the software 
modules, the processing modules 11,21 and 3 1 and the API modules 12, 22 and 32 may 
be implemented as hard- wired electronic circuits or other programmed integrated or 

20 other electronic circuits or devices. The memories 13, 23 and 33 may include any 

suitable data storage devices, such as magnetic disk or tape storage devices, volatile or 
non-volatile semiconductor devices, optical disk storage devices, etc. 

Using the API modules, the systems may communicate with each other in a way 
that is independent of the other functions, operating systems or capabilities of the 

25 systems. As discussed above, the API modules can structure the content of messages 
sent between the systems based on a defined purpose for the commimications using a set 
of information packets known to each of the API modules. That is, information that is to 
be sent between the systems 1, 2 and/or 3 may be associated with one or more 
appropriate information packets that are then assembled into a message and sent. (As 

30 discussed above, the term "information packet" does not refer to packetized transmission 
protocols. Instead, "information packef refers to predefined message portions that may 
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be used to structure a message as described in more detail below. Messages generated 
using "information packets" may be sent by packetized transmission protocols, or not, as 
the transmission protocol used is not important to this aspect of the invention.) The 
message may include a header information packet that includes information indicating 
the defined purpose for communication. The system receiving the message may use the 
communication purpose information to determine which information packets are 
included in the message and use the information associated with the information packets 
for any suitable purpose. 

As a brief example described in more detail below, a user of the applicant system 
1 may use the system 1 to send a message regarding a loan application to the financing 
network 2. The user may indicate a purpose for communication, e.g., "loan application", 
to the system 1 and then provide information to be sent in a message to the financing 
network 2. The API module 12 may identify, e.g., select based on a purpose for 
communication, a set of information packets to be used when constructing the message 
based on the defined communication purpose "loan application'', and assign information 
for the message to the appropriate information packets. Once the information to be sent 
has been properly associated with the information packets to be used to structure the 
message, the message can be sent to the financing network 2. Since the financing 
network 2 receiving the message can identify the communication purpose for the 
message, e.g., from the header information packet, the financing network 2 can 
determine which information packets are included in the message and retrieve needed 
information firom appropriate information packets or variables. 

Fig. 2 is a flow chart of steps that may be performed, for example, by any of the 
applicant system 1, financing network 2 and/or lender system 3 when communicating. 
Although the illustrative embodiment shown in Fig. 1 is used to help explain the steps in 
the Fig. 2 flow chart, it should be understood that the steps of this method need not be 
performed only on a system like that in Fig. 1 . Instead, aspects of the invention may be 
implemented in any suitable environment, system or set of systems. 

In step SIO, definitions for information packets are provided. The definitions for 
information packets may be provided in any suitable way, including storing definitions in 
the memories 13, 23 or 32, sending definitions for information packets from one system 
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to another, e.g., from the financing network 2 to the applicant system 1, or in other 
manners. In one example used herein to explain an illustrative embodiment, information 
packet definitions are stored in the memories 13, 23 and 33. 

The definitions for the information packets may define a set of variables that are 
5 associated with each information packet. For example, definitions may be provided for 
information packets related to a consumer or business address, asset information, a credit 
bureau report, consumer or business financial information, a credit reference, 
employment information, equipment information, a list of alternate identification 
information for a consumer or business, and others. Any suitable variables, or fields, 

10 may be associated with an information packet, e.g., an information packet for a consumer 
address may be associated with variables for a street, city, ZIP code, coxmtry, and phone 
number. An exemplary set of information packet definitions is provided in Table 1 
below and in the incorporated U.S. Provisional Application 60/251,077 in sections 6.3 of 
Documents 1, 2 and 3. An information packet may have one or more variables 

15 associated with it, and the variables may have any suitable type, such as number, string, 
integer, character, a number range, a flag, and so on. Information packets may also 
reference other information packets in some cases, e.g., an information packet for 
consumer financial information may be associated with a number of variables as well as 
an information packet for consimier address information. 

20 In step S20, a purpose for communication between devices in a financing services 

network is defined. The purpose for communication may be defined in any suitable way. 
For example, a user of the applicant system 1 may indicate a purpose for communication 
by inputting information through an input/output (I/O) device, such as a voice 
recognition system, keyboard, touch screen, a graphical user interface, etc. The 

25 information representing the purpose for communication may be input in response to 

prompting by the applicant system 1, e.g., the applicant system 1 may request the user to 
indicate whether communications with a financing network 2 are for a loan application or 
a line of credit. Thus, the purpose for communication may be defined by a single value, 
representing, for example, "loan application", "syndication", "letter of credit", etc., or by 

30 a plurality of values. For example, a hierarchy of values may be used to define the 

purpose for communication. As discussed above, a first level in the hierarchy may define 
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a financing service to be accessed, a second level may define the type of customer 
accessing the service, a third level may define the financing option selected for the 
transaction, and so on. The user may provide information to define the commvmication 
purpose in any suitable way, such as by selecting a particular Internet website page (e,g., 
where each of a plurality of different pages are associated with different communication 
purposes), by entering information into appropriate areas of a graphical user interface, by 
selecting a set of values displayed in a graphical user interface, and so on. In another 
embodiment, the applicant system 1 may extract information from data provided by the 
user, e.g., in a loan application form, to determine the commimication purpose. 

Alternately, a purpose for communication may be defined by a communication 
signal received at any of the systems from another system. For example, the lender 
system 3 may receive a signal fi-om the financing network 2 that indicates a purpose for 
communication. The signal may explicitly define one or more parameters that indicate 
the purpose for communication, or the system receiving the signal may determine the 
purpose for communication from attributes of a received message, e.g., a received 
message that includes a loan application may itself represent a purpose for the 
communication is "loan application". 

In step S30, a set of one or more information packets that are to be used to 
structure the content of a message sent between the devices is determined. The set of 
information packets used to structure the content of the mess^e may be determined 
based on the purpose of communications defined in step S20. Thus, for example, 
communications relating to a loan application may be structured using a first set of 
information packets and communications relating to a line of credit transaction may be 
structured using a second, different set of information packets. If a plurality of 
parameters is used to define the purpose for communication, the set of information 
packets used for structuring the content of messages may be selected based on the set of 
parameters. Since the set of information packets may be determined based on the 
purpose for a communication, devices receiving messages that participate in 
communications having a defined purpose can anticipate and/or readily parse infomiation 
received in a message. This is because the information packets may be drawn from a set 
of standard information packets, both the set and the structure of each available 
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information packet type being known to the device receiving a message, and each of a 
plurahty of communication purposes may be associated with known sets of information 
packets as meaningful information. As such, data can be extracted from the information 
packets in a message and used in proper context. 

Each message sent between devices may also include an information packet that 
includes header information. The API header information packet may include variables 
associated with information for the sender's identification, a timestamp, a transaction 
identifier, a return address, as well as values that define the purpose for communication, 
such as values for different levels in a hierarchy. This header information packet can be 
used by a receivmg device to identify what the purpose for communication is, who sent 
the message, when and where the message was sent, and so on. 

In step S40, a value for at least one variable for at least one information packet in 
the message is defined. As discussed above, variables associated with an information 
packet may take any suitable form and may be associated with string-type information, 
numeric information, etc. Values may be provided in any suitable way for the variables. 
For example, a user may enter values by keyboard or other user interface, e.g., when 
completing a loan application form on the applicant system 1 . Values may also be 
obtained from other information sources, such as previously sent messages, a database, 
such as a consxmier credit information bureau, and so on. Thus, a user need not provide 
all of the information used to define values for variables associated with an information 
packet. 

In step S50, the message is sent, e.g., from one device to another in a financing 
services network. The message need not be sent directly between devices, and instead 
may be sent, for example, from an applicant system 1 to a financing network 2, which 
then forwards the message, or a similar message to the lender system 3. As discussed 
above, the message may be sent in any suitable way using any suitable protocol and/or 
communication channel. For example, the message may be sent through a 
telecommunications network, the Internet, a local area or wide area network, whether 
wired or wireless, or any suitable combination of such systems. 

To further illustrate several aspects of the invention, an illustrative embodiment is 
described below in which the Fig. 1 system is used to communicate regarding a financing 
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transaction. In this embodiment, the API modules 12, 22, 32 use a 7-level hierarchy 
shown in Fig. 3 to define a purpose for communication. Level I in the hierarchy is an 
overall financing service to be accessed by a user of the apphcant system 1 , wliich may 
include a transaction clearing service (such as a loan application decisioning service, 
syndication service, etc.), authentication services (such as a service to verify the true 
identity of a particular consumer or business or to detect credit or other fraud), or 
payment services (such as credit card or other debt payment services). In this illustrative 
embodiment, the user accesses a graphical user interface (GUI) that presents value 
options for Level I that the user selects. By selecting a value for levels in the hierarchy, 
the user can define a purpose for communication. Fig. 4 shows values selected by/for the 
user in this illustrative embodiment. For this transaction, the user has selected the value 
"Transaction Clearing Service" for Level I in the hierarchy. Values selected in certain 
levels in the hierarchy may affect the possible values that may be selected or otherwise 
defined for other levels. For example, certain options may not be available to certain 
types of customers or for certain types of financing services. Thus, if the user selects 
values from a graphical user interface to define a purpose for communication, the 
selectable values displayed by the graphical user interface for other levels may be 
adjusted based on one or more defined values in the hierarchy. 

Level II in this example relates to the type of customer accessing the financing 
service, such as a consumer or business type customer. The customer tjrpes in this level 
may be fiirther broken down into customer types in addition to the business and 
consumer types. For example, the business type may be broken down into small, 
medium and large business sizes, etc. Such fiarther breakdowns for items in various 
levels of the hierarchy may be made within the level itself, or in other sublevels. For 
example, Level II may provide for the types "consumer'' and "business", and a sublevel 
IIA may be provided for the customer subtypes of small, mediimi and large businesses. 
This general notion applies to all levels in the hierarchy, not just Level II in this specific 
example. In Fig. 4, the user has selected the value "Consumer" for Level II in this 
transaction. 

Level III in this example relates to financing options for the customer. Such 
options may include trade financing, working capital financing, equipment financing and 
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other financing options. Financing options that involve a form of lending may include 
secured and/or unsecured forms of lending. In Fig. 4, the user has selected the value 
"Trade Financing" for Level III. 

Level IV of the hierarchy includes items related to particular financing products 

5 that are available to the customer. As with any of the other levels in the hierarchy, items 
in Level IV of the hierarchy may be dependent upon values in other levels in the 
hierarchy. For example, particular financing products may be available to business type 
customers (Level 11), but not to consumer type customers. Similarly, the types of 
available financing products may depend upon a selected financing option fi:om Level 

10 III. In this illustrative embodiment, available financing products may include single 
payment loans, term loans, installment loans, revolving loans, a line of credit, letter of 
credit, and so on. In the example shown in Fig. 4, the user has selected the value "Term 
Loan" for Level IV. 

The hierarchy also includes Levels V, VI and VII. These levels in the hierarchy 
15 define transactions (Level V) that are to be performed based on values for at least one of 
Levels I-IV, operations (Level VI) that are performed for each transaction, and 
information packets (Level VII) that are used in performing the transactions and 
operations. In this illustrative embodiment, the user does not select, adjust or otherwise 
directly define values for Levels V-VII, although it may be possible for the user to define 
20 values for Levels V-VIL Instead, these values are defined by the API module 12, 22 or 
32. Any one of Levels V, VI and VII may depend upon other levels in the hierarchy. 
For example, in this illustrative embodiment, the transactions level in the hierarchy 
depends upon values in Levels I-IV, the operations level depends upon the transactions 
level, and the information packets level depends upon Levels II-IV and VI in the 
25 hierarchy. 

Values for the Levels I-IV in the example shown in Fig. 4 require the transaction 

NewCredit (Level V) to be implemented. In this example, the transaction NewCredit 
requires the operations LookupBusinesses, ReturnBusinesses, GetApplicationForm, 
ReturnApplicationForm, SubmitApplication, ReturnApplicationReference, 
30 GetDecisionStatus, ReturnDecisionStatuSy and Submitlnfo, Since the operations level 
items depend upon the transactions level (Level V), a given transaction, such as 
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NewCredit, will always require the same set of operations. Thus, it is possible for other 
value sets for Levels I-IV of the hierarchy to require the transaction NewCredit to be 
implemented. In this example, other value sets that require the transaction NewCredit 
will always require the same set of operations. However, it will be understood that 
5 dependencies in this illustrative embodiment may be altered in any suitable way. 

The information packets needed to implement the transaction NewCredit are also 
listed in Fig. 4. In this example, the items at the information packets level (Level VII) 
depend upon at least one upper level in the hierarchy, such as Levels II-V. For example, 
different information packets may be used to implement the transaction NewCredit and 
r^z 10 its associated operations depending on whether the customer is a Consumer or Business 

customer as indicated in Level II in the hierarchy. Similarly, a different set of 
!3 information packets may be used to implement the transaction NewCredit depending 

"T: upon values for other levels in the hierarchy, such as Levels III and IV. 

Fig. 5 shows an exemplary correspondence between the information packets used 
15 and each operation executed to implement the NewCredit transaction in this embodiment. 
For example, the LookupBusinesses operation requires the information packet <lookup- 
business-criteria>, and so on. Thus, this correspondence shows which information 
==1^ packets will be used when performing each corresponding operation in the transaction 

NewCredit. Several of the information packets listed in Fig. 5 as corresponding to a 
20 particular operation are actually combination information packets that refer to two or 
more information packets. This shorthand form is not required and is used to simplify 
the presentation in Fig. 5 by eliminating the need to include a list of several information 
packets for each operation. Figs. 7 and 8 provide a complete list of information packets 
that relate to each combination information packet in this illustrative embodiment. 
25 Further information regarding the fields, or variables, that may be associated with each 
information packet in this illustrative embodiment are provided in the incorporated U.S. 
Provisional Application Serial No. 60/251,077, e.g., in section 6.3 of Documents 1-3 in 
the provisional application. 

Fig. 6 shows a set of messages that are sent between an applicant system 1 , 
30 financing network 2 and a lender system 3 in an illustrative embodiment when executing 
the transaction NewCredit, The set of messages sent as shown in Fig. 6 occurs after a 
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purpose for communication has been defined, e.g., by the user entering values for one or 
more levels in Levels I-IV of the hierarchy shown in Fig. 3. As discussed above, a user 
at the applicant system 1 may define the purpose for communication, for example, by 
selecting values in a graphical user interface for different levels in the hierarchy. The 
5 purpose for communication in this example is that shown in Fig. 4. The purpose for 
communication may be represented by values from Levels I-VI in the hierarchy that are 
included in message header information packets. Once the purpose for communication is 
defined, the API module 21 may identify tiie transaction(s), operation(s) and information 
packet(s) to be used to structure messages sent when performing the transaction. Thus, 
10 in a first communication (Commvinication A) in implementing the transaction NewCredit 
as shown in Fig. 6, a LookupBusinesses operation is performed. In general, each 
operation included in this illustrative embodiment involves sending a single message, but 
operations may include sending/receiving two or more messages and/or other fianctions. 
In this example, the LookupBusinesses operation involves sending a message from tiie 
15 applicant system 1 to tiie financing network 2 including the corresponding information 
packet <lookup-business-criteria> as well as an API header information packet. This 
message set may be used to request the financing network 2 to search a database for 
information related to tiie consiraier requesting the financmg services. For example, tiie 
consumer may be an individual wishing to purchase a good or service from a merchant 
20 that maintains the applicant system 1 . Merchant personnel may use the 

LookupBusinesses operation to request the financing network 2 to retrieve stored 
information related to the consumer. The financing network 2 implements tiie 
ReturnBusinesses operation and sends back a messs^e (Communciation B) that includes 
information identified in tiie search requested in the LookupBusinesses operation. As 
25 with the other messages sent when implementing an operation, the information contained 
in the message is structured using the information packets associated witii the operation 
being performed. The message may include no information, e.g., if the financing 
network 2 did not find any records meeting tiie search criteria, or a list of one or more 
records that met the search criteria. 
30 A user at the applicant system 1 may use information m the message sent from 

the financing network 2 to carry the transaction forward, e.g., select a record provided in 
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the ReturnBusinesses message that relates to the consumer and use the information in the 
record to complete an application form. Alternately, if the ReturnBusinesses message 
did not include any information related to the consumer, or if the LookupBusinesses 
message was never sent (e.g., in the case that the user knows that the financing network 2 
does not include any information related to the consumer), the message (Communication 
C) sent when implementing the GetApplicationForm operation may request a blank 
application form related to the requested fmancing service. The message may include an 
indication of which information sent with the ReturnBusinesses message relates to the 
applicant. The fmancing network 2 may send back the ReturnApplicationForm message 
(Communication D) that includes the blank application form. Not necessarily all of the 
fields in the blank application form may be empty. Instead, any suitable number of the 
fields may be filled in by the fmancing network 2 using appropriate information, such as 
information identified in the GetApplicationForm message as relating to the appUcant, 
and so on, before sending the form to the application system 1 . 

After receiving the application form, the user may provide information to 
complete the appHcation, e.g., by typing information into appropriate areas of a graphical 
user interface. Once the apphcation form is complete, the SubmitApplication message 
(Communication E) may be sent to the fmancing network 2. The 
ReturnApplicationReference message (Communication F) may be sent back to the 
applicant system 1 to acknowledge receipt of the application and possibly indicating 
other information, such as reference information for the application, such as an 
application number. 

The fmancing network 2 may also send a SubmitApplication message 
(Communication G) to one or more lender systems 3, thereby submitting the application 
to one or more lenders for consideration. This SubmitApplication message may have the 
same structure as the SubmitApplication message received from the applicant system 1. 
This capability allows the application to easily be sent to multiple lender systems 3 if 
desired, since no special processing is required for each message sent to a lender. The 
lender system 3 may return a ReturnDecisionStatus message (Communication H) 
acknowledging the application submission and communicating the lender system 3's 
current status, e.g., currently processing application. As needed, the lender system 3 may 
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send additional ReturnDecisionStatus messages (Communication I) to the financing 
network 2, for example, to request additional information such as a personal guarantor 
for the applicant requesting the loan. The financing network 2 may acknowledge the 
message, e.g., by sending the Acknowledge message (Communication J). 
5 At any point in the process, the applicant system 1 may send a GetDecisionStatus 

message (Communication K) to the financing network 2 to check on the current status of 
the loan application for a plurality of lenders. The financing network 2 may return a 
ReturnDecisionStatus message (Communication L) that includes any suitable 
information, such as a status last reported by the lender system 3, an information request, 
10 such as the personal guarantor (PG) request sent in Communication I, and so on. In 
response to a ReturnDecisionStatus message that requests fiirther information, the 
applicant system 1 may send a Submitlnfo message (Communication M) that includes the 
requested information. The financing network 2 may acknowledge receipt of the 
Submitlnfo message and forward the Submitlnfo message (Communication N) to the 
15 appropriate lender system 3. This type of interactive communication capability is a 

unique aspect of this illustrative embodiment. Thus, a lender system 3 need not simply 
reject an appUcation, but instead may request further information, such as an adjustment 
in loan terms, guarantor information, and so on to allow approval of the application. 
Once the application is approved, a ReturnDecisionStatus message 
20 (Communication Q) may be sent from the lender system 3 to the financing network 2, 
which may acknowledge receipt of the message (Communication R) and forward it 
(Communication T) to the applicant system 1 either on its own or in response to a 
GetDecisionStatus message (Commimication S) sent by the applicant system 1 to the 
financing network 2. The customer may accept the lender's approval in a Submitlnfo 
25 message (Communication U) sent to the financing network 2, which may forward the 
Submitlnfo message (Communication V) to the lender system 3, The lender system 3 
may acknowledge the transaction is complete with a ReturnDecisionStatus message 
(Communication Y) that may be acknowledged by the financing network 2 and 
forwarded to the applicant system 1 (Communication Z). 
30 It shoxild be understood that the above description is only one illustrative example 

for one transaction that may be executed by the illustrative embodiment. It should be 
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understood that various aspects of the invention should in no way be limited to this or 
other examples provided herein. 

Although particular embodiments of the invention are described in detail, various 
modifications and improvements will readily occur to those skilled in the art. Such 
5 modifications and improvements are intended to be part of this disclosure and v^ithin the 
spirit and scope of the invention. Accordingly, the description of the illustrative 
embodiments is by way of example only and the invention is defined, at least in part, by 
the following claims and their equivalents. 

10 

Table 1 

<acknowledgement> 



An information packet that contains a response acknowledgement plus any completion 
codes 



Field 


Description 


; Domain : Req 


Validation 


n\ Sender Id 


eCredit.com assigned id for the 


jChar 10 


Y 






sender of the request or notify 


1 








message 








S3 Event Id 


Unique id for the request or 


Ichar 10 '. 








notify message. 








Completion 


1 Level of error 


iChar 10 : 


Y 


Completion Code list 


Code 




Ichar ■ 






Message 


Completion message text 




N 








'lOO 






15 <address> 


Field 


Description 


; Domain ; Req 


Validation 


Address 1 


The first address line 


iChar 30 : 


Y 


1 

! 


Address 2 


.Additional address line 


ichar 30 


N 




City 




•Char 30 




1 


State/Province 




iChar 10 ' 


Y 


State Abbreviation 






1 




list 


Zip/Postal Code 


Char 10 


Y 




Country 


Country 


Char 30 


Y 


1 Country list 


Phone 


: Phone number 


iChar 13 


N 


(Required for 










<business-address> 
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Phone ; jChar 13 ^ N | 
Extension ; \ 




<api-header> 

This is the standard information packet for all API messages. 


Field Name Description i Domain ! Req | Validation 


API Version API version for this message phar2 J Y r2"forV3.1 
Sender Id ^eCredit.com assigned id for the |Char 10 ; Y j 
.sender of this message ! [ 


Event Id Unique id for this message. IChar 10 Y j 

j ^ 1 

Event The local date and time that the iChar20 i Y 
Submission sender submitted this message | 
Timestamp ^ ^ 


Unique Id provided by 
the Sender 
Format: 

"yyyymmdd hh:ram:ss" 


Event Time The time zone where this jChar6 Y 
Zone message is submitted expressed [ 

as the time difference from ? 

Coordinated Universal Time 

(UTC). 

I ; 

GFNSiteld The GFN site where this [Char 10 J N 
application is being processed. ! [ 


±HH:MM. EST="- 
05:00", CST="-06:00", 

MST="-07:00", 
PST="-08:00". This 
should be adjusted for 
Daylight Savings Time 
where applicable. 


RetumlP Return address of the site where Char 255; N 
Address this message originated. This | ; 

could be an IP address or a URL. I 
Service Type 'eCredit.com code for this type of iChar 30 Y 

service ; ■ 


Format: 

"xxx.xxx.xxx.xxx" for 
a retimi IP address. 
Service list 


Customer Type eCredit.com code for this type of |Char 30 

customer J 
Form Factor eCredit.com code for this form jchar 30 

factor i 
Facility eCredit.com code for this facility tChar 30 

type 1 
Transaction eCredit.com code for this [Char 30 

transaction ; 


Y 'Customer list 

i 

Y [Form Factor list 

Y Facility list 

Y [rransaction list 


Operation eCredit.com code for this jChar30 Y Operation list 
operation ! j 

Merchant Id eCredit.com assigned id for the jChar 60 Y jValid merchant Id 
merchant ! | 

Lender Id eCredit.com assigned id for the jChar 60 N j Valid lender Id 
lender 1 i ! 
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Field Name 



Description 



j Domain ' Req \ 



Ic 



Validation 



Application 'An id for this application that is Char 60 N | 
Number unique to the merchant. I 



<applicatioii-iiifo> 



Field 



Description 



Domain j Req j 



Validation 



Approved 

Name 

Status 

Decision 



iName of customer approved by 
the lender 



Char 30 ; Y 



TeCredlEcom-s^^ [Char 20 , Y |Decision Status list 

notification j ; 

eCredit.com-specific Decision ^Char 20 \ Y [Decision list 

Code i i 



Decision State ^eCredit.com-specific Decision Char 30 Y IDecision State list 
State I I 

<application-reference> 

Provides a reference to the specific application that may be used to get a decision status 
or populate an application form. 



Field 


Description 


j Domain i Req \ Validation 


Merchant Id 


:eCreditxom assigned id for the 
merchant 


jCharlO: Y i Valid merchant Id 


Application 
Number 


An unique id provided by the 
merchant for this application. 


]char 10 Y j 



<approved-values> 

<approved-*> information packets are only provided when the Decision is "Approved'" 



Field Description 


Domain ; Req i Validation 


Submitted Name of customer £is provided 
Name by the merchant 


Char 30 ; Y 




Approved Name of customer approved by 
Name the lender 
Approved Address of customer approved 
Address by the lender 


Char 30 1 Y 
Char 30 Y 

^ ^ ; „ 




Approved City . 
Approved State ! 


Char 30 Y | 
Char 10 ' Y f 


Approved Zip j Char 10 N 
Approved Amount of the credit line INumeric N 
Credit Line approved by the lender t 




Approved Date this credit line will lapse if Char 20 ■ N 
Credit Line not used. j 
Expiry . 1 


Format: 
"yyyymmdd 
hh:mm:ss" 
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Field 


Description 


\ Domain '< Req j 


Validation 


Authorized 


Approved authorization amount 


jNumericI 


N iRequiredif 


Amount 




; Authorization Code is 






i 


Jprovided 


Authorization 


The authorization code from the 


Ichar 20 


N i 


Required if Authorized 


Code 


lender for the approved loan 


1 

-L L 


1 


Amount is provided 


Terms 


Trhe text of the terms and 


iChar ; 


N i 




Conditions Text conditions for this credit line 


'8191 


i 




■mfo> 


Field 


Description 


Domain, Req : 


Validation 


Asset Type 


Type of asset 


Char 50; 


Y 1 




Asset 


The manufacturer of the asset 


Char 50 






Manufacturer 




Char 50 


! 
1 




Asset 


Description of Asset to be 


N 




Description 


; financed 









Asset Model 


The model number of the asset 


Char 50 


Y 




Num 




•Char 50 ^ 






Asset Serial 


The serial number of the asset 


Y 




Num 










Asset Condition Condition of Asset 


"^harTO- 


Y 


Asset Condition list 


Asset Quantity 


Number of units 


Numeri 
c 


Y 


Asset Cost 


Material cost of asset 


.Numeri ; 


Y 




Asset Tax 


Sales tax cost of asset 


c 

:Numeri 
c 


N 


I 

, — 


Asset S&H 


Shipping and handling cost of 


Numeri 


N 






asset 


jc 






Asset Other 


Other costs of asset 


Numeri 


N 




Cost 




c 






Address 1 


The first address line of the asset iChar 30 


N 






.shipping address 






1 


Address 2 


Additional address line 


".Char 30 " 


N 




City 




Char 30 


N 


I 

1 State Abbreviation 


State/Province 




•Char 10 


N 










list 


Zip/Postal Code 


Char 10 


N 




Country 


Country of the asset shipping 


Char 30 


' N 


Country list 


Phone 


(Phone number 


Char 13 


N 




Phone 




bhar 13 


N 




Extension 


i 
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<bank-reference> 



Field Description ! Domain; Reg j Validation 



Bank Ref Name Name of the bank reference 


Char 30 Y ; 


Bank Ref First name of the officer at the 

Officer First bank 

Name 

Bank Ref -Last name of the officer at the 

Officer Last bank 

Name 


CharSOi Y i 

: i 
I \ 

Char 30' Y | 

1 ! 

: 1 


Bank Ref Phone number for the bank 

Phone officer 

Bank Ref • 

Phone 

Extension 


Char 13 Y j 

Char 13' N j 

1 
I 

I - - 


Bank Ref Date = Date the account was opened 
Opened 

Bank Ref Acct Names on the account at bank 
Name ^reference 


iCharg . Y ^ 

i 

Char 30 Y 


yyyymmdd 


Bank Ref Acct Type of account 
Type 

Bank Ref Acct Account number at bank 
Number reference 


tehar30; Y 
Char 20 Y 


Bank Account Type 

list 


Bank Ref Acct [Current balance for the accoxmt ! Char 20! N 
Balance . ! 





<bureau-report> 



Field Description Domain' Reg j Validation 

Bureau Report The text ofthe requested bureau Char ^ Y \ 

Text report 4095 j 



<bureau-report-reference> 



Field Description Domain; Reql Validation 

Bureau Code Code name for this bureau Char 30 Y jsureaulist 

Bxireau Event GFN-generated unique id for this: Char 30 Y j 

Id bureau request. ^ ; ! 

BureaulEvent |The local date and time of the ~ Char 20'' Y^jFormat: 
Submission bureau request :"yyyymmdd 

Datetime ;hh:mm:ss" 

<busmess-contact-info> 

Information about an individual contact at the Business. 



Field 



Description 



Domain Req j Validation 
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Name of contact at the customer 
site : 


Char 30 


Y 1 

1 






Contact First 
Name 


^CharSO^ 


'Y"i 

i 






Contact Phone 


, Phone number of customer ;Char 1 3 , 
contact 


Y ! 




Contact Phone 
Extension 


.Char 13' 


N 




Contact Fax 


Tax number of customer contact 


Char 13' 


N i 






Contact Email 


Email for the customer contact 


Char 40 


N 1 






<busmess-financials> 












Financial information about the business 










Field 


Description 


Domain Req 


Validation 


Annual 
Revenue 


Annual revenue for this applicant INumeri ] 


Y 






Business Net 
Worth 


The current net worth of this 
: business 


Numeri , 
c 








Checking 
Balance 


The current balance in the 
business checking account 


Numeri ; 

c \ 


Y 






<busmess-guarantor-info> 


Field 


^ Description 


Domain ^ Req 




Validation 


Business 
Relationship 


Type of relationship between the 
guarantor and the business 
applicant 


Char 30 


Y 


^Business Relationship 

Slist 

i 


Percent 
Ownership 


Percentage of ownership in the 

.company 


Nxmieri : 
.c - 


N 


! 




Amount Limit 


Maximum amount this guarantor j 
is willing to guarantee ! 


N 




<busiiiess-info> 


Field 


Description 


Domains Req 


Validation 


Legal Name 


Name of the business customer 
of merchant 


;Char 50 ; 


Y 




DBA Name 


"Doing business as name 




N 






Business Tax Id The federal tax id for this 
business 


Char 20 ■ 


N 






Business Ticker Ticker symbol for this business 


;Char 20 ? 


N 


1 




Business Legal Typ^ of business such as 
Entity Type corporation, partnership, 
proprietorship 


Char 40 


Y 


[Legal Entity Type list 

1 
1 
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Business Type of industry 
Industry Type • 


Char 40 


N I 


Industry Type list 


Applicant Duns Dun and Bradstreet number for 
No this customer, if known 
Business Start .Year that the business started 
Year 


iChar9 , 

sChar4 [ 


Y 


"YYYY" 


<consumer"financials> 


Field \ Description 


I Domain 


Req 


Validation 


Net Worth Personal net worth of the 

owner/consumer 
Annual Income ;Annual income of the 


[Numeri 
jc . 
Numeri 


N 
Y 





owner/consumer 



Other Income Any other income eamed by the 
consumer 

Other Income Source of the other income 
Source ^earned by the applicant 



Numeri ; N ^Required if 

c 1 jOtherlncomeSource is 

[ iprovided 



Char 30 N 



Required if Other 
Income is provided 



Monthly housing payment 



INumeri Y 

Ic 



Monthly 
Housing 

Payment j ' j 
Residence Type !Type of residence (owner, renter, iChar 20 ! Y iResidence Type list 
^etc.) i L J 



Resident Since Year the consumer moved into j Char 4 . N ; 

the current residence i ; i 



<consumer-mfo> 



Field Description 


Domain Req 


Validation 


Salutation 

First name Given name of consumer 


Char 20^ N j 
Char 30^ Y 


Salutation list 


Middle Initial Middle initial [Char 5 ; N 
Last name Surname of the consumer jChar 30 ; Y 




Name suffix The generation name of the [Char 10 N 

'consumer J ^ 
Month of Birth Month of the date of birth for the j Char 8 : Y 
i consumer | 


Name Suffix list 
Format: "MM" 


Day of Birth Day of the date of birth for the 

: consumer 

Year of Birth Year of the date of birth for the 
consumer 


Char 8 Y 

Ichar8 Y 

i 


Format: "DD" 

'.Format: "YYYY" 

i . 



consumer 



Personal Id 
Type 



Type of personal id presented j Char 20 N iPersonal Id Type list 
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Personal Id 
Issuer 
Personal Id 
Number 



Bureau 
Authorization 

Email 



Name of issuer for the personal 
Id 



lChar30 N 



Number from the identification 
document 



Char 30 



Jf Yes, the consumer has granted 
:the lender authorization access 
bureau data 

Email for the consumer 



Char 2 



N 



I 



Y (Must be "Y" or"N" 



rChar"40^ 



N 



<credit-line-mfo> 



Field Description ! Domain ^Req 


Validation 


Lender Name Name of lender approving the ^Char 60 Y 
credit line i ; 




Credit Line Amount of the credit line jNumerici Y 
approved by the lender i 




Credit Line Date this credit line will lapse if jchar 20 i Y 
Expiry not used. | j 


Format: 

"yyyymmdd 
hh:mm:ss" 


Credit Amount available in the credit [Numeric Y 
Available line ; 




Annual The APR for this lease or loan jNumeric; Y 
Percentage Rate ^ i 





<credit-Ime-refereiice> 



Provides a reference to the specific application that may be used to get a decision status 
or populate an application form. 



Field Description 


Domain | Req i Validation 


Lender Id eCredit.com assigned id for the 
lender 


Char 10 ^ Y 


Valid lender Id 


Lender Account ^ Lender assigned id for the 
Number customer 


Char 10 Y 





<credit-reference> 

This may be used for either credit reference or trade reference. 

Field Description Domain ^ Req j Validation 

Credit Ref Name of the credit reference iChar 30 : Y ^ 

Name ^ ' ' _ \ 

Credit Ref Contact first name for the credit ^Char30 Y^J^ 

Contact First reference ; ! 

Name ' \ 



-28- 



CreditRef Contact last name for the credit ^ Char 30 Y : 
Contact Last reference ; j 

Name ; ' ; j 

Credit Kef Phone number of liie credit iChar 13 ; y = 

Phone ;reference contact ^ \ ^ 

~ "™<:harl3; N 
Phone ! 

Extension ^ ^ _ 

Ocedit Ref Acct Account number for tiSe credit 'Char 20 N 
Num 'reference, if applicable ^ ; j 



<credit-request> 



Information about the specific financial details for this credit application 



Field 


Description ; Domain Req 


Validation 


Amount 
Requested 


Credit line requested by the jNumeri ; Y 
customer. c 




Term 


Lease or loan term requested for Numeri N 
^this application, in months \c ; 


Default: 36 


<customer-reference> 






Provides a reference to the specific customer that may be used to populate a new credit 
application form. 


Field 


Description j Domain » Req 


Validation 


Customer 
Number 


An unique id provided by tChar 10 Y 
eCreditxom for this customer, j 




<decision-response> 


Field 


Description :Domami Req 


1 Validation 


Lender Id 


eCredit.com assigned id for the 1 Char 60 ^ Y 

lender 


1 Valid lender Id 

i 

I 


Lender 

Application 

Number 


Lender assigned id for this credit Char 30 Y 
, application 


\ 

I 


Customer 
Reply 


The customer's reply to a jCharSO. N 
s returned lender decision status : 


j Customer Reply list 

1 



<document-reference> 



This information packet represents a handle to a lender-generated docimient. 

Field Description > Domain i Req ] Validation 

Document Id i Unique Id number for this \ Char : Y 1 ^ 
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document 


[100 




Document 


Identifying string to display to 


] Char 




Title 


c the user 


1 100 


Y 1 



<employment-info> 



Field 



Description 



i Domain > Req j 



Validation 



Employee 
Work Phone 
Employee 
Work Phone 
Extension 
Employer 
Name 

Employee Year 

employment 

started 



The work phone number of the jChar 13 Y jlncluding area code, 
applicant > !with no separators. 



IChax 13 : N 



The name of the applicant's 
employer 

The year that the applicant 
started working for this 

employer 



tChar20 ' Y \ 



:Char4 Y [Integer format: YYYY 



Employee Job 
Title 



Job title of the employee 



!Char 20 TJob Title Ust" 



<equipment-info> 



Field Description 


Domain i Req 


Validation 


Equipment [Description of equipment to be 
Description financed 


Char 50 J Y 

! 




Equipment CostiTotal cost of the equipment 


Numeric! Y ' 




Equipment Tax - Sales tax cost of equipment 


Numeric! N 




Equipment ^Shipping and handling cost of 
S&H lequipment 


NumericT N 

1 
: 




Equipment ! Other costs of equipment iNumeric 
Other Cost i ! 


N 




Address 1 jThe first address line of the jChar 30 ; N 
^ equipment shipping address j i 




Address 2 [Additional address line (Char 30 






City 1 jChar 30 


rNi 


State/Province 1 |Char 10 


N {State Abbreviation 

Jlist 


Zip/Postal Codel jChar 1 0 


N 




Country ! Country of the equipment 

1 shipping 


(Char 30 


N 


Country list 


Phone j Phone number 


jChar iT 


^ n"^ 




Phone j jChar 13 ^ N i 
Extension r \ \ \ 
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<equipment-misc> 



Field 


Description 


1 Domain Req ! 


Validation 


Security 


Security deposit paid for the 


iNiimeric; N | 





Deposit equipment 

Down Payment Number of months of payment 

applied as a down payment for 

this transaction 



INumeric. N Integers 0, 1^2, etc. 



Down Payment Credit Card Number to be used jChar 30 

Credit Card :for down payment. : 

Number ! 

Down Payment : Credit Card Expiration Date |Char 10 

Credit Card ; ; 

Expiration Date I 
Residual 



N [Number with no blanks 
|or punctuation between 
jthe digits 

N jFormat: "mm/yy)^" 



; Residual value of the equipment |Numeric^ N 



<extended-address> 

This information packet is a parsed version of the <address> information packet. This is 
primarily used to support bureau lookups. 



Field 



Description 



i Domain i Req i 



VaUdation 



Street Number Address street number for SChar 10 Y ! 

; consumer ' ' ! 

Predirectional Street directional such as North, [Char 5 N {Street Directional list 

'South, East, West, SE, NW, etc. ! \ 



Street Name 


' Street name for the consumer 


iChar 30 


Y 


1 


Postdirectional 


Street directional such as North, 
South, East, West, SE, NW, etc. | 


|Char5 ; 


N 


1 Street Directional list 


Street Type 


Type of street for the consumer, 
e.g.. Street, Road, Drive, etc. 


IChar 30 


Y 


[street Type list 

i 


Address 2 


Second line of address. 
Apartment or Unit for consumer 1 
addresses 


iChar 30 ' 


N 


1 
1 

1 


City 




jChar 30 


Y 


j 


State 




jChar 10 ■ 


Y 


i State Abbreviation 

ilist 


Zip/Postal Code Postal or zip code for consumer 


sChar 10 \ 


Y 


i 


Country 


Coimtry for the consumer 


[Char 30 ! 


Y 


[Country list 


Phone 




fChar lIT 


"Y 


\ 
1 


Phone 


; !Char 13 ! 


N 


Extension 


1 i 

1 : 


! 1 







5 <information-request> 



Field 



Description 



i Domain [ Req ^ 



Validation 
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Information 
Type 


Type of information that is being|Char 30 : 
requested j \ 


Y 


Information Type list 


5r-decision> 


Field 


; Description J Domain Req 


Validation 


Lender Id 


eCreditxom assigned id for the jChar 60 
; lender j 


Y 


Valid lender Id 


Lender Contact |Name of the lender contact 


Char 30 ; 


N 




Lender Contact 
Phone 


Phone number for the lender {Char 13 \ 
contact j ; 


N 





Lender Contact 
Phone 

Extension 


Char 13 ; 


N 




Lender Account! Lender assigned id for the 
Number i customer 


Char 30 > 


N 




Lender 

Application 

Number 


Lender assigned id for this credit 
; application 


Char 30 ; 


Y 




Status 


.eCredit.com-specific Status 
notification 


Char 20 


Y 


Decision Status list 


Decision 


^.^^ ^ — J — , 

eCredit.com-specific Decision 

!Code 


^har20^ 


Y 


Decision list 

1- - 


Decision State 


eCredit. corn-specific Decision 

'State 


Char 30 


Y 


Decision State list 


Decision Code Lender assigned code 
1 


Char 10 \ 


N 




Decision Code 

2 


Lender assigned code 


Char 10 : 






Decision Code 
3 


Xender assigned code 


Char 10 , 


N 




Decision Code 

4 


Lender assigned code 


Char 10 ; 


N 




Decision Code 
5 


Lender assigned code 


iChar 10 


N 




Decision 
Reason 1 


Lender assigned reason ;Char 80 

i i ' 


N 


i 


Decision 
Reason 2 


Lender assigned reason 


iChar 80 

i 


N 


I 
i 

i 


Decision 
Reason 3 


Lender assigned reason 


jChar 80 

i 


N 


1 


Decision 
Reason 4 


Lender assigned reason 


jChar 80 

t 


N 


i 
1 


Decision 
Reason 5 


Lender assigned reason 


jcharSO 

I 
i 

^ — „ „ J 


N 


t 
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Field 



Description 



^ Domain Req j 



Validation 



Disclaimer TextThe text of the disclaimer for |Char ^ N 
this credit line i2000 \ 



Comment Comments from the lender to the j Char 
merchant or customer S255 



N 



<list-of-similars-choice> 



Field Description 


[Domain Req 


Validation 


Bureau code -Code name for this bureau jCharSO Y 
Bureau number Number from the bureau. This iCharSO^ N 

is the file number from Experian [ ! 

:or the DUNS number from Dunn; 

and Bradstreet j ' 


Bureau list 




Company Name of the company found 
Name 

CompanyAddre j Address of the company found 

ss i 


|Char 30 ^ N 

i 1 
jChar 30 N 

1 I 




City 
State 


iChar 30 N 
ichar30; N 




Accuracy Accuracy rating 


jNxmieric; N 


1 



<lookup-application-criteria> 



Field 


Description 


! Domain ^ Req 


Validation 


Applicant 


Name of the business customer 


iChar 30 ! 


Y 




Name 


of merchant 








Application 
Number 


An unique id provided by the 
merchant for the application 


iChar 10 ? 
Ichar 10 ^ 


N 




Lender 

Application 

Number 


'An unique id provided by the 
lender for the application 


1 


N 




Customer 


.An unique id for the customer 


jChar 10 


N 




Number 










Lender Account An unique id provided by the 
Number lender for the customer 


|Char 10 : 


N 




Decision 


eCredit.com-specific Decision 
Code 


;Char 20 ' 


N 


Decision list 


Decision State 


eCredit.com-specific Decision 
State 


iCharSO 


N 


iDecision State list 


From 


Application Decision status after IChar 20 
this date-time i : 


N 


'Format: 

"yyyymmdd hh:mm" 


To 


Application Decision status 
before this date-time 


jChar20 

1 


N 


Format: 

["j^yymmdd hh:mm" 
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<Iookup-business-criteria> 

Information packet that specifies the criteria for looking up a business customer. 



Field 


Description 


j Domain 


Req j Validation 


Applicant 


Name of the merchant's 


jChar 30 


Y J 


Name 


customer 


i 




City 




iChar 30 


N 


State/Province 




TChar 10 

i 


N j State Abbreviation 

{list 



<origination-info> 

Information that describes the origination information for this application. 



Field 1 Description 


Domain i Req 


Validation 


Merchant Id ' eCredit.com assigned id for the 
merchant 

Application An unique id provided by the 
Number merchant for this application. If 
:not provided, GFN will create a 
unique application number. 


Char 10 1 Y 

i 

Char 10 ; N 


Valid merchant Id 


Channel Type The type of sales channel (e.g. [Char 20 : N 
direct, web etc) where this j ; 
application originated ^ 

Channel ID The merchant-assigned identifier! Char 20 N 
for the specific channel where j 
^this application originated j 




Location Id The merchant-assigned identifier 

of the location (e.g. store or 
branch) where the application 
originated 

Sales Rep Id : Merchant assigned id for the 

sales representative submitting 
this application. 


Char 20 ■ N 
Char 10 i N 


I 


Sales Rep 
Phone 

Sales Rep . 

Phone 

Extension 


Char 13 ; N 
[Char 13 ] N 


Sales Rep Phone 

i 
! 

1 


Sales Rep The email address for the Sales 
Email representative 
Application .Application specific field for 
Field 1 information passed from the 
merchant to the lender 


iChar40 « N 

|Char30 N 

1 


i 

i 

1 
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Application 
Field 2 


Application specific field for jChar 30 ' 
information passed from the i ' 


N 






! merchant to the lender 








Application 
Field 3 


Application specific field for iChar 30 > 
\ information passed from the 






merchant to the lender 








Application 
Field 4 


Application specific field for 
information passed from the 
merchant to the lender 


Char 30 

■ 


N 




Application 
Field 5 


— ,~ ~ - — >r 1 

Application specific field for 

information passed from the 

: merchant to the lender 


Char 30 : 

; 
- 


N 




Comment 


Comments from the merchant or 
[customer 


Char i 
255 ^ 


N 





<program-option> 



Field 


Description 


; Domain; Req ; 


Validation 


Program Option Program option Id for this 
Id financing option. 


iChar 30 


Y 1 


Lender or Merchant- 
specific 


Program Option! Program option name for this 
Name financing option 


^Char 30 \ 


Y 


Examples: Tech 
Refresh 


Term 


Lease or loan term for this 
application, in months 


;Numeri ; 

;c 


N 

■ 




Payment 


Payment for this lease or loan 


Numeri \ 
c 


N 

... 


Aggregate lease or loan 
payment for the 
transaction 


Rate Factor 


Rate factor for this lease or loan 


^Numeri ; 
c 


N 


Expressed as a 
decimal. 0.03 is 3% 


Annual The APR for this lease or loan 
Percentage Rate ^ 


Numeri : 


N 


Expressed as a 
percentage. 20 is 20%. 


Purchase 
Option 


The purchase option for the 
! equipment 


Char 20^ 


N 


Examples: FMV: Fair 
Market Value, 10% 
Buyout, $1 Buyout 


Residual 


Residxial for the equipment 


Numeri \ 
c 


N 




Down Payment Number of months of payment 
applied as a down payment for 
ithis transaction approved 


Numeri \ 
c 


N 


Integers 0, 1,2, etc. 


ort-data> 


Field Name 


Description 


j Domain . Req 


; Validation 


Support Data 
Attribute 


The name for this support data 
attribute 


iChar 50 ' 

L , „ 


Y 
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SxjppcHt Data value of the support data (Char Y 

Value :255 



-support-data-refereiice> 



Field Name 



Description 



Domain ] Req i 



Validation 



Support Data The source of the support data. 
Source 



Char 50 : Y 



Support Data The Id of the event that sourced 
Event Id Ithe data 



Char 30 Y 



<user-login> 



Field Name ' Description 


Domain i Req 


Validation 


Login-id The user's login identifier 


Char 20 Y 




Password iThe password for this account 


Char 20 Y 




Private Key ^The name of the password file 
File generated along with the 
certificate 


Char 50 


N 




Certificate File The name of the Certificate file 
generated by eCredit.com to 
uniquely identify the merchant 


Char 50 


N 





What is claimed is: 



5 



